1. Field of the Disclosure
The present disclosure relates generally to document generation and in particular, to systems and methods for extensible document generation.
2. Description of the Related Art
Computer software such as computer applications often provide feedback to a user via displayed screen messages. These screen messages are generally temporary and will disappear after a certain amount of time. Some applications also have notification or correspondence capabilities for notifying or corresponding with a user and/or one or more third parties. These types of applications generally provide the notification or correspondences on a predefined communication channel. Examples of types of communication channels that may be used include printer, facsimile, mail, SMS/MMS, etc.
The contents of the notification or correspondence may include, for example, confirmation that an action has been taken or directions instructing the user what they should do next. Sometimes, an action may result in a number of notifications or correspondences having to be output to one or more parties. An example might be if a user purchases an item in a buyer portal and their manager wants to confirm the transaction. In this case, the user may get a notification such as a confirmation acknowledging receipt of the purchase request and the manager may get a notification that they need to accept the transaction.
The connection between business processes and the notifications that are to be provided is often customizable. For example, customers can often predefine what content is sent on a certain communication channel to a particular user group for certain business processes. Some applications provide no fixed document generation at all and customers need to create their own documents or tailor existing documents to their own needs. Examples of these types of applications include those that provide functionality to “buy” or “request” items from the system. An example would be a portal such as a learning portal. The learning portal may provide a learning catalog with learning material like class-room courses, web-based or computer-based training, etc. Users (e.g., employees) can look through the catalog and enroll or buy training sessions. The user's manager may request a list of all training sessions in which the user participates. Another example would be an application that provides tracking information, for example, for tracking the status of an item being shipped. Although there may not be any change in the status of a delivery, someone may still request the current status on an item being shipped. In this case, in response to a user request, the application will read the current status of the order, and generate and return to the user a document indicating the current status.
In general, correspondence is a very generic service of an application. In fact, often many different processes may call a generic correspondence service to, for example, send a confirmation. Accordingly, although the correspondence service's functionality itself is independent of the particular process making the call to it, the content of the correspondence generated by the correspondence service depends on the process making the call.
Accordingly, in general a static document is not sent out for all cases. Instead, systems are generally designed to generate a document for each request. The same is true, for example, for requesting pages from a web server. The document generation process is generally template driven. A Template is a document containing both static text and empty spaces or place holders (e.g., attributes) for dynamic content which will be defined at execution time. During document generation, the attributes are filled in by the application with values from the business process. Examples of values that may be filled in include item ID, date, the receiver, etc. Getting the business data into the document being generated can be performed, for example, using interactive forms based on Adobe software. This system uses a template that provides an interface. The interface describes the different fields in the template that need to be filled in order to generate the document. An application generating the document calls the interface of the template and provides the attributes as interface values.
One short coming of present systems is that since the correspondence service is a generic service and there may be many different templates and different interfaces for each business process, the correspondence service has to be aware of every single template that might be called and every single interface. This makes it very difficult to change the template, the interface or add a business process. For example, to add a new field to a template, a new field will need to be added to the interface. In addition, if a new business process is added which requires a new template, it will have to be introduced to the correspondence service so that the correct interface can be generated.
Usually, there is a data provider responsible for filling in the template's interface attribute on a single field level. Accordingly, there may be a different method used for each field.
From the template's point of view, the template depends on the particular business process (e.g., buying, cancellation, etc.) Accordingly, different templates have different interfaces and thus, the application has to know every single interface.
From an application's point of view, it would be a good idea to have different templates that use the same attributes and interfaces. The benefit would be that different documents could be generated by the system if the interface is the same in one generic correspondence service. Accordingly, many of these correspondence services predefine an interface with an enumeration of all possible attributes. Thus, the correspondence service becomes a generic application service. One drawback however, is that the application no longer knows what attributes are actually used in a template. The application always has to fill all fields of the interfaces and this reduces system performance.
In addition, customers may want to enrich the functionality of the correspondence service by adding customer made attributes. For example, a customer may want to add their own branding and/or some additional data to the correspondence. As the attributes are exposed in the interface, adding a new attribute would change the interface which would require changes in the generic correspondence service. These changes may require a substantial amount of code changes. Accordingly, this is quite inflexible from the customer's point of view.
An example of a system having a hard dependency between application, template interface and template is shown FIG. 1. An application 10 makes calls to template interface specific data provider interfaces 12 and 14 to fill the attributes of templates 16, 18, respectively. Data provider interfaces 12, 14 are each responsible for calling data provider 20 and for filling the template interface attributes on a single field level. Accordingly, data provider interfaces uses a specific method for filling each field. Calls by data provider interfaces 12 and 14 are answered by data provider 20 utilizing the data stored in database 22.
One major shortcoming of the above-noted systems is that there are two relationships, one from the application to the template and the other from the application to the data provider. Every change in the template requires an adaptation of the application and every change in the application requires the template to be adapted.